REMARKS 



These remarks are in response to the final Office Action mailed on March 1, 2002, and 
for which a three-month extension is hereby requested. In the Office Action, all of the 
pending claims were rejected under 35 U.S.C. 103(a) based on the reference of Iijima, U.S. 
Patent No. 5,349, 649. It is believed that the invention of the present application differs in a 
number of significant ways from what is presented in the Iijima reference and is not obvious 
from Iijima. Although all of the formerly pending claims are believed allowable as is 
discussed briefly below, they have been cancelled and a new set of claims drawn to 
specifically highlight the various aspects of the present invention that are distinct from the 
prior art are being submitted. Consequently, the present amendment is being filed with a 
Request for Continued Examination (RCE). Additionally, the Applicants thank the Examiner 
for the telephonic interview of August 21, 2002, when the differences between the present 
application and the cited prior art, particularly Iijima and also Users Manual for the 
SupraExpress 288, were discussed. 

The present remarks begin with a discussion of the Iijima patent and then a discussion 
of the present application and how it differs from Iijima. This is followed by a discussion of 
the new claims, a discussion of the new figure and, finally, a discussion of the previous claim 
rejections. 

Iijima, U.S. Patent No. 5,349, 649 

The Iijima patent describes a method for communication when a host and card can use 
two different protocols (A, B) to communicate. This is described there with respect to Figures 
2 A to 5. Figures 2 A and 2B describe operations within the card, Figure 3 describes the 
process in the host. 

The process begins with step ST1 in Figure 2 A, with YES = "card 1 supports only 
protocol A or B [that is, one of either A or B, but not both] (to be referred to as case 1)" and 
goes on to step ST2 (column 3, lines 1-5), and with NO = "protocol A or B can be designated 
[actively chosen] by an external device (to be referred to as case 2 hereinafter)" and goes to 



protocols), with Figure 2A as the single protocol case. In either case, the process then 
proceeds as described at column 3, lines 22-30: 
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step ST14 in Figure 2B (column 3, lines 6-12). 

Figure 2B corresponds to the more relevant case here (where the card supports two 
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"Prior to data communication, a reset signal is supplied from external 
device 7 to CPU 4 [of card]. When this reset signal is disabled, initial data 
called "Answer to Reset" (ANS-TO-RESET) is output from CPU 4 in IC card 
to external device 7. The "Answer to Reset" information includes data 
defining the type of communication protocol supported by IC card 1 . External 
device 7 receives "Answer to Reset" information and checks the 
communication protocol used with IC card 1 . . .". 

In step ST2/ST14, the card determines how to respond to the "Answer to Reset" by indicating 

to the host in which of protocol A or B the card communicates, this being determined by the 

card based on a value stored in the cards memory (column 4, lines 9-24 and 51-57). This 

information is then communicated to the host in a form that the host can understand (column 

3, lines 28-31). 

The "Answer to Reset" is transmitted from the card to host in step 
ST3/ST6/ST15/ST21. That is, the card tells the host which of protocols A and B it can 
support as determined by the card in step ST2/ST14 using a third, standardized protocol in 
which both the host and card can communicate (column 3, lines 32-37; column 4, lines 17-24 
and 58-68). This "Answer to Reset" is then received at the host and the process there is 
described with respect to Figure 3 (column 3, line 32, to column 4, line 2). 

In step ST201 the card tells host what protocol it can support (column 3, lines 34-41). 
In step ST202 the host decides if the card will support the host's protocol based on the 
"Answer to Reset" sent in a language both the host and card can use for this initial 
communication (column 3, lines 42-46). In step ST203, based on the "Answer to Reset", the 
host must actively chose the protocol the card will use by outputting information for selecting 
the protocol the card will use (if card supports more than one and one of these is the host, 
otherwise error ST205) (column 3, lines 47-59). Thus the host selects its own protocol in a 
process that requires an active choice by host — and it is a choice only in a limited sense, in 
that the host either confirms the cards initial choice of protocol as OK or else the host rewrites 
the chosen protocol stored in the cards memory. 

Returning to the card's side of the process, this goes back to step ST4/ST7 in Figure 
2 A, for the case where the card supports only a single protocol, or step ST17/ST23 in Figure 
2B, for the case where the card supports both protocols. In Figure 2A, as the card supports 



only one protocol, either it supports host's protocol or doesn't, in which case an error. In the 



column 4, line 2): "Each external device 7 automatically switches and selects one of the 
protocols from the IC card 1 which supports multi-protocols." This protocol type select signal 
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case of Figure 2B, the host sends a protocol type select signal (PTS) (column 3, line 60, to 
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arrives in steps ST17/ST23 (column 5, lines 1-1 1) and is checked in step ST18/ST24 (column 
5, lines 12). In step ST18/ST24, the host says to the card either, "your protocol is OK" (the 
NO path) or "I don't like your protocol and you need to switch it" (the YES path) in steps 
ST19/ST25. 

In response to the YES in step ST19/ST25, the host tells the card to reset the preferred 
protocol in step ST16/ST22, which had formerly been assumed based on the card's previous 
history. Only at this point is the card ready to receive commands in the host's protocol, step 
ST5/ST8/ST20/ST26, that are sent in step ST204 of Figure 3. 

Thus, Iijima presents two variations. In the first, of Figure 2 A, the card only supports 
one protocol (only one of A and B) which is determined by the card itself. Thus, the card 
does not rely on the host for the selection as the host either accepts the card's protocol or it 
doesn't work. (The card has two protocols and cannot switch by itself, so that the host must 
use the cards chosen protocol; although there is a provision for the host to change the card's 
default protocol as described at column 6, lines 53-61, this can only occur after 
communication has been established using the card's chosen protocol.) In the second case of 
Figure 2B, the card can support two protocols, A and B. In either case (Figure 2A or 2B) the 
host can order the card to switch between A and B, but must first respond in the card's chosen 
protocol. In both cases, the card decides in which protocol to start communication. 

In the device of Iijima, the card always starts up in a predetermined way and the host 
either accepts or does not accept. The card starts communicating and the host can either listen 
or not — if it can, the card happened to start in the correct protocol. If the card supports two 
protocols, the host can change the protocol the card uses, but the card can not change this 
protocol itself. 
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Present Application 



A major aspect of the invention of the present application is also the use of a memory 
card with a host that may be operating in one of several protocols. However, the present 
invention presents a process that is believed to be quite distinct and non-obvious from the 
prior art, including Iijima. 

In the exemplary embodiment of the present invention, the two protocols are 
MultiMediaCard (MMC) protocol and Serial Peripheral Interface (SPI) protocol. As 
described in the application, the SPI protocol is technically a physical communication 
protocol, while MMC is a complete protocol, both physical and logical. As the SPI protocol 
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is only a physical protocol, the logical format used for the SPI case in the exemplary 
embodiment is modeled on the MMC case. In particular, as described at page 6, lines 15-26, 
both protocols in the preferred embodiment accept the same first reset command after power 
up as CMDO as defined in the application. 

The connections of the cards to a host for the MMC case are shown in Figure 1 and for 
the SPI case in Figure 3. The card structure is shown in Figure 2 and the functions of the pins 
in the two exemplary protocols are shown in Figure 4. 

The mode selection process is primarily described in the present application between 
page 6, line 28, and page 8, line 25, of the present application (as amended): 

—In a preferred embodiment according the present invention, every 
card wakes up in the MultiMediaCard mode. If the host intends to 
communicate with the card(s) connected in the Serial Peripheral Interface 
mode, then the host begins the normal Serial Peripheral Interface mode 
initialization procedure by sending (903, Fig. 9) a reset command (CMDO) in 
the command line CMD or the Dataln line and asserting the CS signal of each 
card connected to the host. When the CS signal in the communication bus is 
asserted (negative) by the host during the reception (905, Fig. 9) of the reset 
command (CMDO) ("YES" 907, Fig. 9), each of the cards in the system will 
enter the Serial Peripheral Interface mode. All the subsequent communications 
between the host and the card(s) will then be performed under the Serial 
Peripheral Interface protocol (923, Fig. 9). 

On the other hand, if the host is designed to communicate with the 
card(s) connected in the MultiMediaCard mode, the above-mentioned Serial 
Peripheral Interface initialization step (i.e. sending a reset command in the 
command line CMD or the Dataln line and asserting the CS signal of each card 
connected to the host) will not be performed ("NO" 907, Fig. 9),. However, in 
the preferred embodiment of the present invention, each card is designed to 
wake up in the MultiMediaCard mode if it is not set otherwise. Thus, in the 
present case, the card will remain in the MultiMediaCard mode (911, Fig. 9) 
and will only accept and respond to MultiMediaCard commands issued by the 
host. All communications between the host and the card(s), in this case, will 
be performed under the Multi-Media Card protocol (913, Fig. 9). 

Particularly, by performing the mode selection in the card(s) only, the 
entire mode selection is transparent to the host (911, 921, Fig. 9). In other 
words, the card of the present invention is able to adapt its communication 
protocol to hosts running in either mode (i.e. Serial Peripheral Interface mode 
and MultiMediaCard mode).— 

For example, the card of the present invention can attach to a 
MultiMediaCard host for downloading data from the MultiMediaCard host to 
the card. Then, the card can be removed to a Serial Peripheral Interface host 
for uploading the stored data from the card to the Serial Peripheral Interface 
host. The entire process will be transparent to either the MultiMediaCard host 
or the Serial Peripheral Interface host. Thus each of the two hosts treats the 
card of the present invention as a card designed solely for its corresponding 
protocol (e.g. MultiMediaCard mode for the MultiMediaCard host, or Serial 
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Peripheral Interface mode for the Serial Peripheral Interface host). This 
feature provides tremendous benefits in the portability of data to different 
systems. 

Figure 4 shows the pin assignment of a card of the preferred 
embodiment of the present invention designed to operate in either the 
MultiMediaCard mode or the Serial Peripheral Interface mode. 

When the card is operating under the Serial Peripheral Interface mode, 
pin number one is assigned as the chip select, and pin numbers 2, 4, 5, and 7 
are assigned as Dataln, Vdd, CLK, and DataOut respectively. In addition, pin 
numbers 3 and 6 are assigned as voltage ground. 

On the other hand, when the card is operating under the 
MultiMediaCard mode, pin number one is not used, and pin numbers 2, 4, 5, 
and 7 are assigned as command CMD, Vdd, CL, and DAT respectively. In 
addition, pin numbers 3 and 6 are assigned as voltage ground. It should be 
noted that pin 1 is not used in the MultiMediaCard mode. 

In this preferred embodiment, the Serial Peripheral Interface protocol 
defines the physical link of the communications between the host and the cards 
only. The internal memory storage of the card remains identical. In other 
words, only the card communication protocol is changed to either the 
MultiMediaCard mode or the Serial Peripheral Interface mode depending on 
the host connected. 

From the application point of view, the advantage of the Serial 
Peripheral Interface mode is the capability of using an off-the-shelf host using 
the same card. The flexibility reduces the design-in effort to minimum. The 
disadvantage is the loss of performance of the Serial Peripheral Interface 
system versus MultiMediaCard (lower data transfer rate, fewer cards, hardware 
CS per card etc.). 

This passage has been quoted at length as it illustrates both how the present invention operates 
and how it differs from the process described above for Iijima. Additionally, it is referred to 
below in the discussion of the newly added figure. 

More briefly, the process of the present invention consists of attaching the card to a 
running host in a protocol; the host detects the card and sends an initial reset signal in the 
host's own protocol; in response to reset signal, the card selects the host's protocol based only 
on this initial reset in a way that is entirely transparent to the host. As seen from the host, 
there is no indication that the card operates in anything but the same protocol as the host. 
Furthermore, there is no need for an ISO standardized protocol for initial communication. 

The process of the present invention can be contrasted with that of Iijima. In both the 
present invention and the process of Iijima, a host that runs in a particular protocol has a card 
connected. The host then sends a reset signal to the card. After this, the two processes 
diverge: In the present invention, the card selects the hosts protocol based on this reset signal 
and is ready to receive commands from the host in its protocol at this point, all in a way 
transparent to the host. 
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In contrast, Iijima has a number of additional steps necessary before it can receive 
commands in the hosts protocol. Considering the more relevant case of Figure 2B where the 
card supports two protocols, subsequent to the receiving the reset signal, the card must send 
back to the host a signal ("Answer to Reset", ST 15/21) specifying the protocol the card has 
determined it prefers and which protocols it supports (ST 14), the card having also previously 
determined that it supports two protocols in step STL While the card waits (ST17/ST23), the 
host receives the "Answer to Rest" (ST201), determines if the card has told the host that the 
card supports the host's protocol (ST202) and, if the host needs the non-default protocol, 
sends a signal (Protocol Select Signal or PTS) back to the card telling the card to switch 
protocols before transferring data and commands (ST204). Back at the card, the card checks 
if there is PTS data (ST18/ST24) and decides (ST19/ST25) whether the host is happy with the 
cards choice of protocol and, if not, switches the cards current protocol (ST16/ST22). Only at 
this stage is the card switched into the protocol the host is using to transfer data and 
commands to the card. 

Further, it appears unlikely that the process of Iijima would function with multiple 
cards attached, as described in the present application with respect to Figures 1 and 3 as there 
is no assurance that all attached cards would be operating in the protocol switching mode of 
Iijima's Figure 2B. For example, consider the case where a second card is attached to the 
host/card system of Iijima when a first card is already running. 

Therefore, Iijima does not have the card choose the protocol, this choice is not in 
response to the initial reset received at the card form the host, and is not made in a manner 
transparent to the host. Rather, Iijima teaches away from such a process, having the host 
choose the protocol, actively selecting it in through a series of signal exchanged back and 
forth between the host and card in an additional protocol. Thus, it is respectfully submitted 
that the invention of the present application is quite distinct and non-obvious from what is 
presented in Iijima. This is reflected in the claims. 

The Examiner has previously introduced the Users Manual for the SupraExpress 288 
in the Response to Arguments as support for claim rejections under 35 U.S.C. 103. However, 
the communication method used by this reference is protocol negotiation. The initiating 
device initiates communication using a user selectable protocol, the remote device responds 
using its own choice and the two devices continue trying to communicate using local rules to 
select from a predetermined list of allowable protocols until communication is possible, or 
break the connection and try to communicate using the same procedure at a later time. This is 
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clearly different than the present invention where the protocol selection is transparent to the 
host, in which no negotiation occurs, and communication is always possible as long as the 
host protocol is contained within the card's allowed list of protocols. Thus, the Users Manual 
for the SupraExpress 288 again teaches away from the present invention as embodied in the 
pending claims. 

New Claims 

In order to more clearly delineate these distinctions between the mode select process 
of the present application and those of the prior art, including Iijima, a set of new claims have 
been filed. More specifically, claim 91 has that "based on signals from the host the ... card 
selects the [host's] protocol from a plurality of protocols in a way transparent to the host", 
with claims 87, 92, and 97 drawn to the exemplary embodiment where this selection is made 
based on the initial reset signal from the host. As described above, this is quite distinct and 
non-obvious from the teachings of Iijima where, in response to the reset, the card must 
respond to the host with information on what protocol the card favors ("Answer to Reset") 
and the host has to determine if it is happy with the card's choice and change the card's 
choice if the host wants a different protocol (PTS data). This is also very different from the 
process of the Users Manual for the SupraExpress 288, where the protocol selection is neither 
transparent to the host nor based on the signals from the host. 

Claims 88, 93, 98, and 99 are drawn to the exemplary embodiments of the structure of 
the reset command and card interface. Claims 89, 90, 94, 95, 100, and 101 specify exemplary 
protocols with which the present invention can be used. Claims 96 and 103 note that the 
present invention readily extends to the use of multiple cards with a given host, while claim 
102 describes the use of a single card with multiple hosts having distinct protocols. 

Comments on Previous Office Actions 



As noted above, although the previously pending claims have been cancelled, they are 
believed allowable over the prior art for the reasons stated above with respect to the new 
claims. These distinctions have been discussed in previous responses and will not be repeated 
here as these claims have now been cancelled in favor of the new set of claims drawn to 
specifically highlight the various aspects of the present invention that are distinct from the 
prior art. In addition to distinctions noted above, namely that the claims are not only not 
obvious based upon the Iijima reference, but, rather, that this reference rather teaches away 
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from the present invention as embodied in these claims, it respectfully submitted that the 
Office Action makes several other errors. 

It is respectfully submitted that the Office Action has made a number of improper 
comments related to rejections under 35 U.S.C. 103(a) based upon only a single reference and 
the taking of "Official Notice". In a number of places the Office Action admits that claims 
recite features lacking in the reference, yet there is no further reference or other evidence of 
prior art presented to demonstrate that the overall claimed combinations including the 
elements missing from Iijima would have been obvious. The Office Action either summarily 
states that "it would have been obvious" to add the missing element in order to meet the terms 
of the claims, or "Official Notice" is taken that the elements missing were well known and 
would have been obvious to include in the claimed combinations. In either case, assumptions 
have improperly been made by the Examiner as to what one ordinarily skilled in the art would 
have found obvious to do since there is no supporting evidence provided in the Office Action. 
It is respectfully submitted that these rejections do not make the necessary prima facie case of 
obviousness. For example, the Office Action states that the MMC protocol was well know at 
the time without any supporting evidence. 

The Office Action also states that a number of things are obvious based upon Iijima 
when, as is described above, it is respectfully submitted that Iijima instead teaches away from 
the present invention and that any claims of obviousness are improperly made based upon 
hindsight gained from the present application. 

It is also respectfully submitted that the claims are fully supported by the present 
application in both its specification and its figures. . Although further details related to the 
present invention are presented in the MultiMediaCard specification, there is no reliance upon 
this document for essential material. More specifically, Figures 1 and 3 show the connection 
of cards to host for the MMC and SPI case, respectively, with the bus for data and commands 
shown in both and a chip select line in the SPI case. Figure 2 shows the structure of the card 
with the pin connections and interface driver, including the commands shown in Figure 4, 
including CMD (of which CMDO is an example) at pin 2 and chip select at pin 1. 

All through the features of the currently pending claims are believed to either be 
shown in or inherent from Figures 1-8 of the application, the present Amendment is adding 
Figure 9 in order to facilitate the application process. The contents of this figure are all 
contained in the extended portion of the present application found between page 6, line 18, 
and page 8, line 25, of the application that is quoted at length above and to which 
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corresponding reference numbers have been added. The new figure places these various steps 
in a flow as described in this passage of the application. Consequently, this does not 
constitute the introduction of new matter. Additionally, an appropriate corresponding 
reference to Figure 9 has been added to the "Brief Description of the Drawings" section of the 
specification. 



For any of these reasons, claims 87-103 are believed allowable. Consideration of 
these claims is therefore respectfully requested and an early indication of their allowability is 
earnestly solicited. 
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Conclusion 



EXPRESS MAIL LABEL NO.: 



Respectfully submitted, 



EL873331169US 




Michael G. Cleveland 
Reg. No. 46,030 
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Amended Portion of Specification : 

Please replace the three paragraphs beginning on page 6, line 28, and ending on page 
7, line 18: 

-In a preferred embodiment according the present invention, every card wakes up in 
the MultiMediaCard mode. If the host intends to communicate with the card(s) connected in 
the Serial Peripheral Interface mode, then the host begins the normal Serial Peripheral 
Interface mode initialization procedure by sending (903, Fig. 9) a reset command (CMD0) in 
the command line CMD or the Dataln line and asserting the CS signal of each card connected 
to the host. When the CS signal in the communication bus is asserted (negative) by the host 
during the reception (905, Fig. 9) of the reset command (CMDO ) ("YES" 907, Fig. 9\ each of 
the cards in the system will enter the Serial Peripheral Interface mode. All the subsequent 
communications between the host and the card(s) will then be performed under the Serial 
Peripheral Interface protocol (923, Fig. 9) . 

On the other hand, if the host is designed to communicate with the card(s) connected 
in the MultiMediaCard mode, the above-mentioned Serial Peripheral Interface initialization 
step (i.e. sending a reset command in the command line CMD or the Dataln line and asserting 
the CS signal of each card connected to the host) will not be performed ("NO" 907, Fig. 9) ,. 
However, in the preferred embodiment of the present invention, each card is designed to wake 
up in the MultiMediaCard mode if it is not set otherwise. Thus, in the present case, the card 
will remain in the MultiMediaCard mode (911, Fig. 9) and will only accept and respond to 
MultiMediaCard commands issued by the host. All communications between the host and the 
card(s), in this case, will be performed under the Multi-Media Card protocol (913, Fig. 9) . 

Particularly, by performing the mode selection in the card(s) only, the entire mode 
selection is transparent to the host (911, 921, Fig. 9) . In other words, the card of the present 
invention is able to adapt its communication protocol to hosts running in either mode (i.e. 
Serial Peripheral Interface mode and MultiMediaCard mode).- 

Pending Claims 

(Claims 1-86 have been cancelled) 



87. A memory card connectable to a master operating in a first 
communication protocol, comprising: 
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an interface for connection to the master for the transfer of data and commands 
between the host and the memory card; 

a memory section for storing said data; and 

an interface controller connected to the memory section and the interface, 
wherein the interface controller selects said first communication protocol from a plurality of 
protocols based solely on an initial reset signal received from the master upon connection to 
the master. 

88. The memory card of claim 87, wherein the interface comprises a 
plurality of connection pins and wherein said initial reset command comprises asserting a first 
signal level to a first connection pins when the host operates in the first protocol and not 
asserting said the first signal level to the first connection pins when the host does not operate 
in the first protocol. 

89. The memory card of claim 88, wherein said asserting a first signal level 
is the assertion of a chip select signal and wherein the first protocol is a Serial Peripheral 
Interface protocol. 

90. The memory card of claim 88, wherein the first protocol is a 
MultiMediaCard protocol. 

91. A system comprising: 

a host that operates in a first communication protocol; and 
a first card connectable to the host for transferring data and commands 
between the first card and the host, wherein based on signals from the host the first card 
selects the first protocol from a plurality of protocols in a way transparent to the host. 

92. The system of claim 91, wherein the first card selects the first protocol 
in response to an initial signal from the host when the first card is connected to the host. 

93. The system of claim 92, wherein the first card comprises an interface 
through which the data and commands are transferred, the interface comprising a pin, and 
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wherein the reset signal comprises asserting a signal to said pin that is dependent upon said 
first protocol. 

94. The system of claim 93 , wherein said first protocol is a Serial 
Peripheral Interface protocol and said signal is a chip select signal. 

95. The system of claim 93, wherein said first protocol is a 
MultiMediaCard protocol. 

96. The system of claim 91, further comprising: 

a second card connectable to the host simultaneously with the first card for 
transferring data and commands between the second card and the host, wherein the second 
card selects the first protocol from a plurality of protocols in a way transparent to the host. 

97. A method comprising: 

connecting a first memory card capable of communicating in a plurality of 
communication protocols to a first host operating in a first of said plurality of communication 
protocols; 

in response to said connecting the first memory card to the first host, 
transmitting a reset command from the first host to the first card; 

receiving the reset command in the first card; and 

the first memory card selecting the first communication protocol for the 
transfer of data and commands between the first host and the first memory card based solely 
on the reset command. 

98. The method of claim 97, wherein said reset command comprises 
asserting a chip select signal. 

99. The method of claim 98, wherein the first card subsequently remains in 
said first protocol when the chip select signal is de-asserted. 

100. The method of claim 98, wherein the first communication protocol is a 
Serial Peripheral Interface protocol. 
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101. The method of claim 97, wherein the first communication protocol is a 
MultiMediaCard protocol. 

102. The method of claim 97, further comprising: 

transferring first data from the first host to the first memory card using the first 
communication protocol; 

disconnecting the first memory card from the first host; 

connecting the first memory card to a second host operating in a second of said 
plurality of communication protocols; 

in response to said connecting the first memory card to the second host, 
transmitting a reset command from the second host to the first card; 

receiving the reset command from the second host in the first card; 

the first memory card selecting the second communication protocol for the 
transfer of data and commands between the second host and the first memory card based 
solely on the reset command from the second host; and 

transferring the first data from the first memory card to the second host using 
the second communication protocol. 

103. The method of claim 97, further comprising: 

connecting a second memory card capable of communicating in the plurality of 
communication protocols to the first host while the first memory card is also attached to the 
first host; 

in response to said connecting the second memory card to the first host, 
transmitting a reset command from the first host to the second card; 

receiving the reset command in the second card; and 

the second memory card selecting the first communication protocol for the 
transfer of data and commands between the first host and the second memory card based 
solely on the reset command. 
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